Postcards From The Edge Case: When One Size Doesn't Fit All

Alex Byrne
Youth Services Librarian
Mastodon: TheyofHIShirts@glammr.us
Twitter: @HeofHIShirts
github.com/HeofHIShirts

for

Open Source Bridge 2016
23 June 2016
#edgecaseOSB
#osb16

The Standard Disclaimer

A few things before we begin.

  • The opinions expressed in this presentation are not necessarily those of my employer, whom I very much like working for. Please do not mistake my opinions for theirs.
  • I have attempted to accurately convey the opinions of others based on their published work. If I'm wrong about this, please let me know so I can make corrections.
  • No logo or image used in this presentation, or mention of any other project, implies endorsement from the owners and/or maintainers of those projects.

What Gives You The Right?

I'm mostly an end user and documentation writer for things. While I have been known to follow someone else's clever hack or idea of putting something to use for a purpose other than what it was intended, I'm not necessarily the person that's elbows-deep in the source code or trying to find ways of obtaining root in new technologies. But, in a lot of the contexts of my life around me, I'm an edge case, a power user, or someone who's thinking of things in a different light than others. Some of these reasons are physical, others generational, and still others because no two brains think about how to use things in exactly the same way. If you look at your own life, you will probably find that you, too, are an edge case somewhere. So you have the right to think about these things, too.

A lot of my examples are going to come from interacting with physical space and the implications for software and hardware that might entail. Since more and more of our applications are becoming augmented-reality or have accompanying pieces of hardware to have to interact with, thinking about space in the design is a thing to be reckoned with.

Postcards From The Edge Case

One: Design for Giants

One of the first ways that I discover a design flaw is by hitting my head on it. thwack "OW." is a fairly common way for me to understand that whatever space I am in, or item that I am interacting with, was not designed for me.

According to the CDC's Anthropometric Statistics for 2007-2010, the average height for a United States man is 175.9 cm, or 69.252 inches - five feet, nine inches. In bare socks, I'm about seven inches taller than the average, plus one more in shoes, generally speaking. Eight inches is a lot of space to strike one's head on. Or, in the cases of several roller coaster over-the-shoulder restraints and the panoramic X-ray device at my dentist's office, to feel extremely uncomfortable as an object presses very strongly down on my shoulders for the duration of the experience.

A local grocery store near my work was running a Monopoly-related promotion in the store, and they had strung oversize versions of the Monopoly money across the top of the checkstand lights. Which were situated quite well above the space that most people would be passing through to put their groceries on the converyor belt. The selfie that you see, with my forehead obscured by the Monopoly money string, was taken at head height. Every time I went to that store during the promotion, I had to duck under the tightly-strung money, usually because I forgot from the last time and ran into it again.

Then there's this picture of the work desk I had in May of 2016. While the camera's tilted a little bit up in this picture, it's pretty apparent that my hips are well above the working surface of the desk. It has a benefit, in that I can bend fully at the waist and lean across the entire surface to talk to very small children on the other side (sometimes frightening them terribly), but it also produces problems if I want to stand and type. The monitors and keyboard are on something that is adjustable, but adjusting it upward makes the entire apparatus feel flimsy when typed on, it leaves a large area underneath the keyboard tray that could be hazardous, were something to break, and more practically, the cords from the computer and monitor don't actually stretch that far up without severe strain placed on them. Even if I wanted to adjust things, it makes the workspace less functional instead of more. The desk that replaces this one is adjustable-height, and moves the desk surface itself up and down, instead of just having one element of the desk be adjustable. My wrists and arms thank the new desk design for its help.

How does this translate to software? Well, even the biggest smartphones can feel pretty tiny when you have relatively large hands. Trying to play, for example, a time-limited match-three game that depends on both accurately seeing the board and being able to make precise movements can be an exercise in frustration when the fingertip used for the movement can cover more than one of the elements of the gameboard. Since it's a game, it's mildly inconvenient, but there will be other places where the frustration levels will be greater.

After all, little things, repeated often enough, can still add up to big aggravations.

The caveat to designing for giants is that you still have to design for your audience. My library system offers a good reason why someone would not want to design for giants in the use of varied-height shelving for different collections of materials. The picture book and beginning reader shelves are at the height of the left shelf in this picture, which makes them great for the young children that are the primary audience of picture books and beginning readers. Picture books and beginning readers are on the smallest shelves, elementary and middle-grade books are on an intermediate-height shelf, and teen and adult books are on the tallest shelves. By using height differences, the collection's intended audiences are marked more clearly and it provides a handy visual reference, much like those height charts at the roller coaster rides, of the level of the books.

While the bigs that accompany these littles may find the child-sized design problematic, because they're bigs (and possibly bigs with mobility issues and difficulties in getting to the appropraite child-sized level), the need to provide an appropriately-sized space for the primary audience (rightly) overrules the comfort of those who are outside the audience. That said, there are couches and furniture that the bigs can use to sit and get down to child level for interaction, at least.

Accessibility concerns also go here as caveats. Designing for giants is great, but, especially in places that have to deal with the Americans With Disabilities Act or other guidance that has certain requirements, those requirements have to be met in the design.

Two: Be Secure Without Sacrificing Functionality

There's a clear need for security in computing applications, and especially those that handle any sort of personal data. Companies want to be sure that their information isn't being leaked out or mishandled and that their workers aren't bringing in viruses, worms, and other horrible things past the network firewalls to wreak merry havoc on the machines inside the suppsoedly safe zone. I get the need for security. It is important.

First and foremost, the public computers used a shared login whose Internet access has been filtered fairly heavily in the way one might expect a corporation to do, by blocking "game sites", "download sites", and a few other categories that an office worker in an office building wouldn't necessarily need to go visit a whole lot of the time. The problems with this type of blocking decisions came through in force when attempting to staff test the latest iteration of our summer program for teens, Teen Summer Challenge A category of activities devoted to Nintendo, another to the Ludum Dare challenge, and a third devoted to Pokémon all ran into the same issue - "games" sites were blocked, so the activities that asked people to design a classic Super Mario Brothers level or look at the entries from the latest Ludum Dare could not be completed on staff computers that hadn't specifically had their filters turned off. On those same computers, if someone wanted to know more information about an upcoming game or wanted to read reviews of it, the staff computers might not be able to provide that information because of the filter's inability to distinguish between sites with news content and sites that were offering various games to play while on work time. If the site had a keyword that involved gaming, then the site was blocked. Certainly a good way of securing the computers against possible intrusions, but the overblocking zeal interfered with the functionality of a legitimate enterprise for the library system.

Then there's the software issues on all of the library's computers, whether their Internet access is filtered or not. I can see the reasons why my organization decided that when our computers got upgraded, they were all going to be a single image, with a predetermined suite of software installed on them and an enterprise rule that said no other programs could be installed on the machines and nothing other than what was already installed and on the whitelist would be allowed to execute. Trying to get the smallest amount of exposed attack space possible while still providing enough software for the normal functioning of the library is a perfectly valid goal and choice.

I understand that having a single image also makes it easier to troubleshoot what's going on, easier to make replacements if necessary, and easier to engage in damage control if something does manage to get out and try to find something to start playing with. These are all sensible security decisions. And they don't work at all in supporting the work that I do as part of my job as a Youth Services Librarian.

My work location has an HD television on one of the walls, attached to a gaming system that the teens use after school, and a small computer that's hiding in the same cabinet that runs a bit of Javascript through a web browser and creates a slide show that tells the teens about programs, about things they can access with their library card, and that displays copies of the artwork they've created for the system-wide poetry, prose, drawing and photography contest the library system runs every year, Our Own Expressions, or the artwork that I've digitized, inked, and sometimes colored from the work of the invisible art collective that draws on the easel pads left in the teen area. Creating the artwork and making it into a form that's ready to go on the slideshow isn't difficult - the image manipulation program works pretty well for that. What does become difficult is when the promotional material that comes out of the Communication department is all in PDF form, assuming you want to print it, when it needs to be in a more common image form to work in the slideshow. The image manipulation program installed on the work machine can't open PDFs as images.

The GNU Image Manipulation Program (GIMP) can. But the sensible security policy says that you can't install programs on the hard drive that aren't already there. No problem, right? All you have to do is grab a spare flash drive and then use the Portable Apps version of GIMP. No installation, no problem, right? Not so much. That other part of the policy that says you can't run any programs on work machines stops the portable versions from running, too. Since it's unlikely that anyone in Communications is ever going to develop a static image version of the fliers, this means the solutions that are likely are things like taking a screenshot with the file open and saving that in the image manipulation program to create the image needed for the slide show. Which is clunky, and only works to a maximum monitor resolution. But how many people outside of the Communications Department need to do anything with PDF manipulation or creation of promotional material, anyway? It's clearly just edge cases that would need such a thing.

Not to mention that a large part of librarianship work, for both kids and adults, is making decisions about programs and evaluating tools that might help in their owrk or their programming. With a security policy like this in place, nobody will be able to test whatever the successor to Minecraft is on work computers and work time, because they won't be able to install it. Nobody could make decisions about whether to offer programs that could teach Twine for building stories and fictions, or software mentioned in Thursday Bram's Open Source Writing Stack talk from OSB 2015 - Markdown, Scribus, or other programs and programming environments without first getting it cleared through IT and then having it installed on multiple machines from the single image. This resticts the likelihood of software usage only to those things that you can build a consensus of need for. Being an edge case generally means your needs are overlapping, but different than anyone else's.

How does that work with the design of software, hardware, or open source projects?

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:

  1. Respect the privacy of others.
  2. Think before you type.
  3. With great power comes great responsibility.

The sudo lecture describes a pretty good balance between security and functionality - prevent unauthorized sharing, give a user an out before they do something that will be considered sharing, and give the user an appropriate warning about the severity of what they are about to do before you let them go through with it anyway. If the design is clear and helpful, the user will have a good idea of what they are about to do when they tap or click OK.

Three: Destructive and Non-Destructive Things Should Not Share Space

Following right on from this comment about good signposting, in May 2016, Vellum Atlanta lost a music library to Apple Music, where the material on their local drive was replaced by material from Apple Music, and then ceased functioning when the trial subscription to Apple Music stopped. Thankfully, they were able to restore a backup, but it was not a happy time. Serenity Caldwell suggests that there was confusion about what actually happened, and provides a tweet from Jason Snell with a dialog box that may have been the culprit.

This dialog box is a nightmare waiting to happen. There are two options to get rid of something on one dialog box, one which will delete the local copy of a thing, one which will remove the reference to Apple Music. Guess which one gets rid of the local copy?

"Remove Download".

(Headpiano)

There's a much better way of doing it, and Ghaati Masala shows how Lightroom handles the same situation - a much clearer explanation, better-labeled buttons, and the default action set to the non-destructive option. I still think this is dangerous, because accidental clicks or getting zoned out and not paying attention can still result in destructive actions. Far better to require conscious action and decision-making to activate the destructive options.

Okay, so this particular example doesn't apply just to edge cases, but there are a lot of programs where I see on the (advanced) options screens things that allow users to choose destructive options along with non-destructive ones. They can be signposted particularly well, or given a "Do Not Touch" box to help someone to avoid clicking on them accidentally, but it seems like a good design decision to shunt destructive options to their own specific menu so as to avoid the temptation to see what the button does, and whether pushing it will fix whatever problem has driven someone this far into the options menus.

(Nirvaaaaaana!)

You'll want to do this because...

Four: Edge Cases Find Lesser-Used Functions Useful

In fact, they might be looking at you specifically because you have a function that will work really well for them. Or that you have a program that's close to what they want and you have a really large suite of possible options for them to go tweaking around in to see if it's only the default configuration that's not quite right for them. The endless ability to tinker until things are just so is something useful for keeping your edge cases happy with you, because giving them the ability to do things the way they want to will please them, even as it potentially intimidates away regular users. So, y'know, moderation and all that, or a really good set of defaults and lots of signposts for those that want to go off into the wild on their own.

Positive examples are things like Barnes and Noble Nook tablets - they're cheap devices that can be tweaked or full-converted to Android devices for less cost than actual Android tablets. Or how Moonlight Game Streaming transforms certain nVidia video cards into streaming platforms for Android or iOS devices, including remote desktop streaming. And how certain cell phone docks made by Motorola can make a Raspberry Pi portable

Sometimes removing things demonstrates how useful they were to edge cases. Another consequence of the computer upgrades is that the DVD-RW drives present on the older computers were removed and replaced with DVD-ROM drives. For the grand majority of library workers, they wouldn't need any reason to write CDs or DVDs, so it makes sense to remove them. Until you get to the Youth Services Librarians, that is, who have programs like Story Time that generally require a customized list of songs set up in a particular order so that there are smooth transitions between all of the activities and rhymes going on and not awkward two-minute interludes of dead air while a librarian desperately scrambles to get the next CD in with a minimum of delay. By removing the ability to burn CDs, one of the important functions of an entire cohort was compromised. But no other cohort would normally use that particular function. Now, Youth Services Librarians are resourceful, and found ways to achieve their goals without rewritable drives, thanks to CD players that came with the ability to read digital music off of flash drives and other technological improvements, but a likely cost-saving measure, combined with the security zeal above, had some serious potential impacts on workers being able to do their work.

Five: Make One Design To Rule Them All

This was about as compressed as the message from David Newton's Talk on Universal Web Design at Open Source Bridge 2015 as you could get. Most helpfully, it's also one of the ways to make sure that your regular users and your edge case users both stay happy with your work and continue to use your program.

Mobile users of websites, app users verus desktop users, and so forth can create headaches if the functions of each of your various methods are different than each other. Edge case users may gravitate to one version and stick with it because it contains the functions they are looking for, and then get mightily upset with you, or jump ship to another program that can implement the same protocol should that function disappear from your program or from the service. Having a single design from the start definitely seems like a more sensible idea. Let's take a look at an example.

Polaris, the Integrated Library System that my public library uses, offers two different forms of our Online Public Access Catalog (OPAC) depending on whether or not the web browser requesting the page identifies itself as a mobile browser or as a desktop client. You can see that the desktop-offered page is full of already-opened segments, with information and recommendations and lots of other fun things glance over, as well as where one might find this particular book. The mobile version of that page is much starker, with a lot less visible information, instead requiring someone to tap on the information they want to see enxt. This makes it less hefty on the bandwidth draw for the initial page, but it then requires more requests to get all the information that is displayed in one shot on the regular page. There's probably a happy medium that could be arranged for both of these designs to merge into one - maybe availability is displayed on both designs by default and some of the other, lesser-used options go hide? It would be nice to dig into the internals of the displays of each of these elements and tailor them so that we can present a unified experience for someone, regardless of whether or not they are coming by mobile device or on a desktop to the OPAC. But that requires either people on your end that can do it or having a good enough in with the people who the programming for your ILS to have them do it for you. If you don't have either of those options, then frustration seems to be your only recourse.

But there isn't even consistency across the desktop versions of Polaris, either. When you first click into the catalog, the search box here has a set of possible options and limiters to use to try and narrow down your search query right from the beginning. That's a great idea to have available right from the start.

…but then when you've actually searched for something in the catalog, new options appear on the results page, options that could have been integrated into the original search page, like the full set of possible options and limiters available to search by and the option to search something as a possible Interlibrary Loan. Many a time have I been frustrated by having to search for something first, and then be able to go back and tailor my query to the exact specifications that I was looking for. I could go straight to the one with the options by clicking on "search catalog" and then clicking on "keyword", but I'd really rather just have the first search box I'm presented with be one that has all the useful options available. (I can understand hiding Interlibrary Loan, since those take longer and get handled differently than in-system requests). There's a lot of duplication and messiness that could probably be cleaned up or folded into one interface, so that the people who have to maintain and develop for that interface only have to keep track of one thing and test it vigorously. This seems like a winning option. It is more difficult than one might think, though, with the proliferation of devices of various sizes, pixel depths, and resolutions, but following the principles of Universal web design in program and app design will probably net some useful improvements - or even avoiding certain pitfalls entirely. Which makes happy users.

And happy users are what you want to have.

So, here's the first batch of postcards again, framed more positively:

  • Design for Giants
  • Be Secure Without Sacrificing Functionality
  • Destructive and Non-Destructive Things Should Not Share Space
  • Edge Cases Find Lesser-Used Functions Useful
  • Make One Design To Rule Them All

These things will help make your software and designs more attractive to a wider swath of the population, beyond the bell curve. Those people will often be your biggest advocates and might even come to work with you on the project so they can help make it better.

And, if nothing else, maybe it will help avoid a few more experiences of hitting their head against something.

Licensing

This presentation is licensed under a Creative Commons 4.0 Attribution-ShareAlike License. Please credit Alex Byrne (abyrne at piercecountylibrary dot org) or TheyofHIShirts@glammr.us or HeofHIShirts for the attribution requirements of any derivative works. Or if you like this work and would like to quote it at someone else.

Any content linked to or used in this presentation, and any video or audio recordings of this presentation may not be governed by this license - please check with the appropriate content owners before reusing any content not specifically governed by this license.